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ABSTRACT 


A major component of modern vehicles is the infotainment system, 
which interfaces with its drivers and passengers. Other mobile 
devices, such as handheld phones and laptops, can relay 
information to the embedded infotainment system through 
Bluetooth and vehicle WiFi. The ability to extract information 
from these systems would help forensic analysts determine the 
general contents that is stored in an infotainment system. Based off 
the data that is extracted, this would help determine what stored 
information is relevant to law enforcement agencies and what 
information is non-essential when it comes to solving criminal 
activities relating to the vehicle itself. This would overall solidify 
the Intelligent Transport System and Vehicular Ad Hoc Network 
infrastructure in combating crime through the use of vehicle 
forensics. Additionally, determining the content of these systems 
will allow forensic analysts to know if they can determine anything 
about the end-user directly and/or indirectly. 


Categories and Subject Descriptors 

[System Forensics]: User/Machine Systems Machine 
information storage and processing, Data acquisition and 
forensics 


Keywords 
Vehicular Ad Hoc Network, Security, Privacy 


1. INTRODUCTION 

The Vehicular Ad Hoc Network (VANET) infrastructure has been 
in development and an active research topic for years now. It has 
seen considerable progress for its proper implementation and 
standardization with collaborations from around the world. This 
infrastructure leads to the implementation of the Intelligent 
Transportation System (ITS), which is a collection of applications 
and services meant for a more efficient, safer and user-friendly 
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transportation system. In VANETs, vehicles will be able to 
communicate with other vehicles directly through peer-to-peer 
means called Vehicle-to-Vehicle communications (V2V) and to 
static infrastructure through Vehicle-to-Infrastructure and 
Infrastructure-to-Vehicle communications (V2I and I2V). 


Vehicle components allow for a vehicle to generate, log and 
exchange data about its surrounding and users in real time. The 
data logged hypothetically gives a third party the ability to analyze 
this data if it manages to access it. According to Illera and Vidal 
[8], data dumps of vehicle crashes are stored into a vehicle’s 
Electronic Control Unit (ECU). These data dumps, if retrieved, 
could grant law enforcement agencies the ability to reconstruct 
accidents and determine the cause of an accident. Data about a 
driver could also be collected if he or she was suspected of criminal 
activities. Infotainment systems inside modern vehicles could tell 
a lot about the end user through his trends and activities, not to 
mention the localization data produced by embedded GPS systems. 
The data logged and circulating inside these vehicles directly relate 
to the driver’s habit since it reflects the users actions. Insurance 
companies, such as the Canadian firm Desjardins, make use of 
hardware modules to monitor these habits. In their service, Ajusto, 
a plug-in-play car attachment used by Desjardins monitors user 
activity. Wall [18] reported that user activity and driving habits are 
measured through the use of the same “black box” units and related 
applications installed in smartphones. This allows good and safe 
drivers to pay less insurance fees since their recorded habits reflect 
lower chances of causing an accident and breaking the law. After 
contacting a Desjardins technical support representative, it was 
confirmed that the data is kept on the Ajusto box locally until 
transmitted. The transmission is done twice a day if still connected 
to its respective cellular network on Canadian soil. If the vehicle 
is outside Canada, the data is stored locally onto the Ajusto device 
until it connects back to the Canadian network. Based off this 
information, the possibility of extracting the information kept on 
these specific devices opens. The ability to verify exactly what 
type of information is kept onto devices such as Ajusto could 
potentially be used to determine information of the vehicle driver. 
Additionally, what needs to be verified is if any of that or related 
information is kept in other components of the vehicle, more 
specifically, the infotainment system. This information can be 
potentially extracted and analyzed by third parties. 


The objective of this paper is to discuss the possibilities of 
vehicular digital forensics and what they could lead to in terms of 
what actual information is stored and what it can disclose about an 
end user and his/her actions. As discussed in [4], privacy is already 
a concern within VANETs. More of these concerns will be raised 


for VANETs and individual vehicle activities depending on the 
findings of this research, however, specifics of this are out of the 
scope of this paper. 


The rest of the paper is organized as follows: Section 2 will discuss 
the internal components of vehicles and their general architecture. 
Section 3 will show modern infotainment systems and their 
potential for vehicular forensics. Section 4 will present work done 
on vehicular forensics. Section 5 will present our preliminary 
results and deductions for what has been found off a logical and file 
system dump of a SYNC infotainment system of a Ford F-150 truck 
and other infotainment systems. Finally, section 6 will conclude 
this paper and present some potential future work in this area of 
research. 


2. VEHICLE COMPONENTS AND 
ARCHETICTURE 


Modern vehicles now make use of many computer buses within 


their internal components to send and receive operational messages. 


Electronic Control Units (ECUs) process this data then actuates 
mechanisms to accomplish tasks requested by the vehicle’s user. 
Vehicles are starting to resemble like actual computer networks and 
each component can be viewed as a node for passing or processing 
information. Some of these components and buses are segregated 
from one another for compartmentalization, however, they are all 
able to communicate with one another to fulfill the vehicle user’s 
demands using the Control Area Network (CAN) bus. As per 
Everett and McCoy [5], there are multiple modules/units and 
respective buses and they are each responsible for specific traffic 
flow inside the vehicle, as depicted in Figure 1. The following list 
is the core networking buses within a vehicle for data exchange: 


e CAN (Controller Area Network) — Core bus that links all buses 
together for data exchange and provides an interface for on-board 
diagnostics. 

e LIN (Local Interconnect Network) — Sub-network used for low- 
speed and bandwidth applications. For e.g., doors and sliding 
windows up and down. 

e FlexRay — Sub-network used for safety critical and high-speed 
messages. For e.g., vehicle stability control and embedded 
sensors. 

e MOST (Media Oriented System Transport) — Sub-network used 
for high-speed and bandwidth multimedia related applications. 
For e.g., music/video streaming and vehicle cameras. 


The following list describes the core modules attached to the 
aforementioned buses. In general, they are found in modern 
vehicles and associated internal networks: 


e Junction Box — provides typical functions for the vehicle’s 
circuits but in this case, connects the OBD II (On-Board 
Diagnostics) port to the CAN bus 

e Engine Control Unit — Controls actuators for the engine to ensure 
optimal performance and does so by reading acquired data from 
multiple sensors through CAN bus 

e Multimedia Head Unit — infotainment system in this case, 
communicates to dash and multimedia displays through MOST 
bus and can receive data from CAN bus as well 
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Figure 1. Vehicle network components and buses [5] 


e Stability Control Unit — uses FlexRay sub-network to engage 
stability control ECUs and actuators and relay/receive 
information to CAN bus 

e Tire Pressure Control Unit — directly affiliated with Tire Pressure 
Monitoring System (TPMS) for relaying information about each 
tire through the CAN bus 

e Telematics Control Unit — controls embedded systems (for e.g. 
GPS unit, 3G/LTE, WiFi communication interfaces) within the 
vehicle through the CAN bus 

e Body Control Unit — uses the LIN bus for engaging door locks, 
window/side mirror positioning, seat positioning, etc. and 
relays/receives information through the CAN bus 

As mentioned above, the CAN network is responsible for 
forwarding all traffic that needs to be relayed between each sub- 
network. It is absolutely vital to the vehicle’s operation since it 
forwards all queries and responses. Error messages also circulate 
on this network for diagnostic messages. End users are then 
notified through the vehicle’s dash display about a present issue. 
Access to a CAN bus could lead to great live vehicular forensics if 
enough data is collected and analyzed correctly. Once connected 
to the CAN, it could grant potential access to separate modules 
within the vehicles and their respective ECUs. This could then lead 
to further vehicular forensic opportunities through non-volatile 
memory. The network/bus used for infotainment/multi-media 
traffic is the MOST bus. The MOST bus makes use of optical fibre 
cables and can now reach speeds of up to 150 Mbps. The speeds 
achieved by this sub-network hint that a lot of information 
circulates on this bus type. 


3. VEHICULAR INFOTAINMENT 
SYSTEMS AND FORENSIC POTENTIAL 


Modern vehicles are becoming quite sophisticated in regards to 
current technologies in terms of internal components. Once 
VANETs are fully implemented, the added layers of 
interconnectivity between vehicle objects will bring transportation 
to the technological frontier. Vehicles are now being embedded 
with high-end infotainment systems with the goal of facilitating 
driving with applications and services for user friendliness, 
efficiency and added security (for e.g., IntelliDrive, a third party 
device which monitors driver habits, can send notifications out to a 
third party insurance company if thresholds are broken). These 
infotainment systems are also embedded with localization services 
and GPSs for easier navigation. From that being said, it is only 
natural that these platforms will produce and circulate a lot of data 
such as media content between external devices, internal logging, 


localization data, etc. The report written by Wall [18] suggests that 
third-party navigation systems have and are most likely collecting 
such information in terms of localization data only. 


There are many infotainment platforms currently deployed in the 
transportation market and are mostly proprietary: Ford SYNC, GM 
OnStar, BMW Assist, Lexus Enform, Toyota Safety Connect, 
Hyundai BlueLink, Infinity Connection, Etc. These platforms are 
some of the interfaces offered to the end users when driving their 
vehicle. These platforms have the goal of making driving 
experiences user-friendly and give the driver and respective 
passengers’ constant connection to the vehicle. Applications are 
offered to interact directly with the vehicle’s systems, for e.g., 
remote start and unlocking/locking doors. Users can stream 
multimedia content from mobile devices for entertainment 
experience. On top of this, Thilakarathna, Petander, Mestre and 
Seneviratne [16] explain that social applications such as Facebook 
and Twitter show prominence due to the increased usage of mobile 
devices and their capabilities, especially now that these mobile 
platforms are being integrated into vehicle functionalities and 
infotainment systems. The combination of the former and latter 
will bring potential to streamlining application services within 
vehicles. Work shown by Guo, Ahmed and Saddik [6] elaborates 
on how web services will be an integral part of vehicles since 
infotainment system are becoming increasingly popular and 
implemented by default into vehicles due to their utility and 
potential resourcefulness. The Internet (and its access) will enable 
these system to directly interact with web services for increased 
functionality and even entertainment of end users within the 
vehicle. Finally, Maaroufi and Pierre [12] discuss the potential of 
VSNs (Vehicular Social Networks) which is the embodiment of the 
aforementioned since it integrates mobile social media applications 
into vehicles, which would redefine its entire community and this 
would allow multiple functionalities and potential. 


A lookout for future Android-powered infotainment platforms 
must also be considered. Recently, many technological giants and 
vehicle manufacturers have formed a coalition entitled “Open 
Automotive Alliance” (for e.g. Google, NVIDIA, Ford, Dodge, etc. 
to name a few — see http:/Awww.openautoalliance.net). This 
coalition’s goal is to provide a common, open source platform for 
vehicles so that a seamless and safer experience is provided. 


Cohen [3] specifically worked with Ford SYNC modules since the 
automaker developed high-end infotainment systems in its current 
market. SYNC, as shown by Cohen [3], runs off a Windows-based 
operating system, Microsoft Automotive, also known as Windows 
CE. It also employs three generations of SYNC modules, 
first/second generation being with older vehicles compared to the 
third one. It is important to note that Cohen’s [3] presentation 
refers to the third generation as the second one and the first/second 
generation refers to the first one. This will simplify references of a 
more recent work that talks about these three generations, having 
the first and second combined. The first/second generation (2007 
— 2011 models) separates the SYNC and navigation modules. The 
SYNC module stores phone related information since it interacts 
mainly with mobile devices. The navigation module (main head 
unit with GPS) stores media files and navigation data through the 
use of a hard drive. The third generation (2011 — 2014/2015) 
integrates both the navigation unit and SYNC module into one and 
employs software-locked SD cards for data storage, wireless 
streaming with 802.11 technology and external media. For 
first/second generation Ford infotainment modules, all the data of 
the SYNC module is stored on a NAND flash chip. Cohen [3] 
shows that through chip extraction, SYNC data can be extracted 
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through raw binary output. It is important to note that the actual 
third generation of SYNC has been released and integrated in 
today’s current Ford models but not much is known as research is 
still underway to gain internal access in these modules. 


Illera and Vidal [8] showed how it is possible to extract data from 
Erasable Programmable Read-Only Memory (EEPROM) 
(discussed below), which allows for more input for data 
reconstruction. Kopylova et al. [10] have researched ways of 
reconstructing accident events more accurately through the use of 
an extended Event Data Recorder (EDR). They have shown four 
approaches to solidify EDRs: 


1. In-vehicle application integration to improve log recording 
(for e.g., access to sensors and diagnostic modules) 
2. Include VANET communications for dynamics 
localization of nearby vehicles while accident occurs 
3. GPS rectification through witness vehicle data 
4. Data sufficiency through rotating logs and use of “accident 
witness” and “self-involved” crash reporting mechanism. 
These added methods shown by Kopylova et al. [10] would make 
accident reconstruction better in terms of event accuracy and detail. 
The latter, more specifically, uses a threaded approach so that 
multiple events can be reported at the same time if a vehicle is 
directly involved in a crash but can report details as a witness to 
other vehicles part of the accident. Overall, all of these would 
ensure that all details from every perspective are communicated 
and stored when gathering information relating to the accident. 
Since ECUs are accessible and contain data in non-volatile fashion, 
infotainment systems are suspected of storing information as well. 
If infotainment information is also kept and stored, the driver’s 
actions and environment could potentially be determined (for e.g., 
multimedia volume strength, GPS breadcrumbs, end-destination, 
etc.). This would help assess an accident reconstruction event 
much better. 


and 


3.1 Forensic challenges in Mobile and Ad Hoc 


Networks 

While remaining in the realm of helping authorities better 
determine events sequences, Mutanga et al. [14] pointed out to the 
challenges of acquiring evidence through digital forensics. Their 
research aims at finding better methods of doing so on wireless Ad- 
Hoc networks, VANETs obviously being taken in consideration in 
this case. The work presented the added challenges of evidence 
collection done onto these types of networks. Here is a list of these 
issues: 


e Mobility — node localization is difficult due to network 
changes 
e Existing security mechanisms — forensics in malicious 
network are easily detectable 
e Topology changes — network state determination is difficult 
because of constant network condition changes 
e Unreliable channels — packet loss due to nature of wireless 
networks 
e Multi-hop communication — source of suspected traffic is 
difficult to trace 
e Low power devices — power constraints for data collection 
and data selection (except for VANET) 
e Interoperability — crime point of origin is difficult to 
determine 
Mutanga et al. [14] showed that Ad-Hoc networks in general give 
malicious users a simplified method of launching attacks from 
nodes as a source onto the Internet. This makes it much harder to 


trace. The use of infotainment system data might help determine 
points of origin through local GPS data acquisition, breadcrumb 
trails and end point destination. The use of vehicle cameras might 
catch the perpetrator in the act (would most likely be using a 
computer device on board a vehicle or tampering with the controls 
on his vehicle). Analysing data remnants of applications used by 
the infotainment systems could also help determine the malicious 
user (for e.g., unknown application being used and/or illegitimate 
uses of legitimate applications). 


Carney [1] makes a case of mobile devices being used more 
extensively for forensic investigations. Although his work is about 
mobile phone devices, the mobility aspect still applies to vehicles. 
Just like mobile device forensics, vehicular forensics is new and the 
concepts apply to either, as vehicles will be able to connect to 
mobile devices through Bluetooth, direct physical interfacing and 
Wi-Fi hotspots. Vehicles could then store the same information, 
and mobile forensic laws could apply the same way so it is 


important to know what is being stored inside infotainment systems. 


Windows-based file systems are quite accessible and, having Ford 
SYNC use Microsoft Automotive as the base operating system, 
makes plenty of information potentially accessible as Schaefer et 
al. [15] have demonstrated through their custom- and community- 
built forensic tools. In regards to localization data, which is of 
value to law enforcement for forensics and investigations, Hannay 
[7] makes a good case for the classification of such data. Figure 2 
summarizes how localization data would be classified in 
accordance to type and confidentiality levels since vehicular data 
acquisition, especially from infotainment systems, would have 
legal boundaries and must be justified. 


Class Identifying Features Confidence 
Implicit - Locational by design High 

- Locational information and 

confidence can be determined without 

significant external information 
Connectivity - Locational information dependent on Variable 
Based extemal data sources 

- Requires additional information to 

determine location 
Metadata - Embedded within an artifact as part Limited 


of secondary functionality 
- Requires additional information to 
determine confidence 


Figure 2: Classification summary [7] 


Infotainment systems, such as Ford’s SYNC modules, have GPSs 
embedded into them when manufactured. Since the infotainment 
platform produces this type of data by design, it is clearly highly 
confidential. It must be determined how this data is stored inside 
the vehicles, and for how long. There is also the multitude of 
metadata produced by current/future in-car applications as well as 
social media applications. Boundaries must be determined, but 
methods to access and determine how the information is stored 
must also be established. 


4. RECENT VEHICULAR FORENSIC 
EFFORTS 


At this state and time, not much work has been put into digital 
forensics of vehicles, especially considering the use of 
infotainment system in modern vehicles. Based off recent trends, 
security vulnerabilities seem to be the main focus for the research 
community in the overall field of VANETs and internal vehicle 
technologies. Checkoway et al. [2], for example, demonstrate how 
the technology within vehicles can be exploited to compromise and 
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control them. Mejri and Ben-Othman [13] even mention that DoS 
(Denial of Services) attacks are more than likely to happen to 
disrupt legitimate services within vehicles and VANETs. Many 
counter-measure must be deployed to ensure user safety hence why 
so much research is invested in the security portion of the field. 
Wei, Yu, and Boukerche [19], for example, discuss such means of 
defense and protection with the use of trust based security methods 
so that interactions are properly evaluated when monitoring 
communications with third-parties. With this in mind, this suggests 
why there is a clear lack of documentation when it comes to the 
aforementioned forensic field. This therefore raises the question of 
the potential of research that can be done in this specific field. Some 
of the first works that touched on vehicle forensics was presented 
at DEFCON 19 by Cohen [3]. The work demonstrated forensic 
techniques employed on the Ford SYNC platforms. The researcher 
has shown vehicle modules can be tapped into to retrieve stored 
data. Chip extraction techniques of NAND flash proved to be 
successful using Data IO Flashpak III, which is a hardware-based 
solution. Overall, regardless of the SYNC generation employed, 
different information can be extracted and is as follows: 


e Bluetooth-paired MAC IDs 

e Phone contacts and logs 

e SMS messages 

e Multimedia files (for e.g., pictures, audio files, videos) 

e Navigation data 

e Generic car information 
The work shown also hints that spare USB ports and JTAG ports 
are accessible. Media and localization data can be retrieved through 
the on-board hard drive. The work shows that reimaging the hard 
drive, exfiltration of data through the upload process and re- 
flashing the firmware are all successful methods of extracting data 
from the hard drive. The second/third generation of SYNC, as 
mentioned in the previous section, integrates both the SYNC 
module and navigation unit using write-protected SD cards that 
contain the Windows-based OS. If this specific card is not present, 
the navigation unit simply does not function as a failsafe. Work 
shown by LeMere’s presentation [11] demonstrates that Ford 
SYNC third generation modules can have data extracted through 
traditional imaging tools and data analysis. JTAG ports are also 
hinted as a possibility and were being looked into for a streamlined 
solution. Flash chips dumps are also achievable but require a 
custom-built solution, which was achieved by LeMere [11]. 


Most vehicles on the road today make use of “black box” modules 
or a Crash Data Retrieval (CDR) function, also known as EDRs, to 
collect information pertaining to a vehicle crash occurring locally. 
The CDR function/EDR stores the data on airbag ECUs since they 
are well protected as shown by Illera and Vidal [8]. This can be 
very useful for reconstructing accident events. Illera and Vidal [8] 
gave a presentation at DEFCON 21 showing how they were able to 
successfully develop custom hardware at very low cost to read and 
write data to/from these modules. They also showed what is 
needed to build them. Proceeding with this, information kept from 
the CDR function relates to the vehicle’s speed, accelerator pedal 
position, brake use, revolutions per minute (RPM), etc. When an 
accident occurs, the data collected by the EDR/CDR function is 
dumped onto the EEPROM of the airbag ECU. The presentation 
points out that there are three ways to retrieve this dumped data: 


1. Extraction through OBD H and CAN bus 
(authentication required) 

2. Extraction through airbag ECU module (authentication 
required) 


port 


3. Direct extraction from EEPROM module (no authentication 
required) 

From what Illera and Vidal [8] showed, ECU authentication is not 
hard to break, but it is much easier with authentication. The 
presentation showed that the software to analyse the data dumps is 
free to download but in need of a parser if you do not want to buy 
expensive hardware that would come with the software. Luckily, 
their custom hardware comes into play and allows for direct 
integration of the EEPROM chip for data extraction. The first two 
methods can also be achieved with this custom hardware since 
Ilera and Vidal [8] show how to break the seed authentication 
process. These techniques demonstrate that data retrieval of non- 
volatile components is possible. 


5. PRELIMANARY RESULTS AND 
ASSUMPTIONS 


Our research group was able to acquire a logical and file system 
dump of a Ford F-150 truck SYNC infotainment’s file system and 
associated content and files. As previously mentioned, it is of a 
Windows based type architecture since SYNC currently runs on 
Microsoft’s automotive OS, Windows CE. As for hardware, the 
interface that connects to the vehicle’s dashboard appears to be 
proprietary as no schemes for its wiring could be found as of now. 
A few USB Mini-B ports have been located but offer limited 
functionality according to reports and testing made by Cohen [3]. 
The SYNC modules, based off current observations, seem to 
mainly interact with themselves, the dashboard and Bluetooth 
devices (assuming the SYNC has the feature offered). The 
dashboard interactions could allow for an infotainment system to 
be directly involved in telematics and communications with 
insurance companies’ “black box” modules for vehicle habit 
reporting but this will need to be further looked into. We would 
need to obtain this device and verify its contents as well if 
interconnection with a separate infotainment system is possible. 
The nature of infotainment systems also suggest that the data 
collected could potentially go beyond the direct interactions of the 
driver and the system itself. Since navigation data has multiple use, 
it could extend this relationship and more data could be captured. 
This needs to be further looked into as a full, thorough analysis of 
a physical dump would need to be obtained and analysed. Multiple 
dumps from other SYNC devices also need to be checked to ensure 
analysis accuracy and replicability. At this state, our other acquired 
SYNC infotainment devices are being analysed for detailed 
information. 


5.1 Data Dump format and details 

The logical dump itself resembles a direct data dump (dd) from a 
POSIX system with encoded metadata which is not be that 
surprising since information such as original file name, checksum 
and disk location can be found. The format relates to one 
understood by special forensics tool. Initially, these dumps were 
accessed and read through the use of the Forensic Toolkit (FTK) 
version 5 data analyser. 


The file system dump contains many “.swf’ (Flash) files since 
SYNC is highly interactive with its UI (User Interface). Ford 
employs the use of DRM as well for protection therefore the use of 
Flash files is appropriate. The fact that Flash is employed does hint 
potential security holes which could be useful in terms of bypassing 
potential security mechanisms, if present, for gaining access to 
stored data for analysis. Direct access to the data inside the file 
system without the FTK and/or special forensics software will be 
nearly impossible since encryption and/or compression is being 
employed on the data itself. The entire payload is then certified 
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with a self-signed Microsoft publisher certificate. From this, we 
are unsure if it is simply a test certificate or if it’s actually being 
authenticated to a CA (Certificate Authority) but if not the latter, 
signing our own payloads will then be easier. The dumps 
themselves seemed to be generated by a built-in dump utility 
employed by Windows CE. The executable is a PE32 ARM 
Thumb which is linked to all the other DLLs (Dynamic-Link 
Libraries) found in Windows CE which itself employs an ARM 
architecture. The VIN (Vehicle Identification Number) has been 
located but more testing will be needed to check if it is encrypted. 
Once the VIN is confirmed, it will be then possible to check 
whether the infotainment system uses some form of authentication 
process using a VIN for booting up. 


5.2 F-150 file system contents 

The acquired F-150 logical and file system dumps gave us access 
to some content of one our SYNC’s infotainment system. 
Compared to the file system dump, the logical one gave us the least 
amount of information to analyse although it is the easiest one to 
acquire in any case. We mainly turned our attention to the file 
system dump since it contained more information as well as the 
same information obtained from the logical one. We recently 
acquired special forensics software such as Encase (trial edition) 
and Autopsy (The Sleuth Kit’s graphical user interface version), we 
analysed all data we could and summed up our findings. It is 
important to know that a decent portion of files and content was in 
an unreadable format through plaintext/transcript form. The use of 
compression and encryption is also adding difficulty to properly 
analysing acquired data. The following list is a preliminary 
compilation of observations and is being presented as a statement 
that establishes that infotainment systems do have the potential to 
withhold user data. It is not limited to only pertinent information 
as the objective is to show what we can obtain from an infotainment 
system by acquiring memory contents, may it be the entire file 
system dump or just parts of it. Here is what we observed from the 
acquired file system contents: 


e “phone book” folder was discovered — XML file found 
containing “Device ID”, “Call name”, “Call Type” and “Call 
Time” (time it was made). Too early to determine if it was a 
call made from a user inside the vehicle connected to the 
infotainment system or if it was received by the vehicle as some 
vehicles have this feature enabled. Potential information 
retained from Bluetooth phone devices connecting to the 
infotainment system, we would need to try with multiple 
phones and check if all of theirs calls are stored when 
connected to the infotainment system 

e Bluetooth connection attempts and potential security PIN 
revealed in hexadecimal format when authenticated (more 
testing required to confirm latter) 

e Infotainment system’s Bluetooth address acquired 
WiFi SSID (Service Set Identification) revealed, associated 
security type and if SSID is broadcasting — helps determine if 
easily accessible 

e logs of USB device connections and respective file structure — 
it was discovered that the system also checks for valid 
installation files when a USB device is connected. Ifa valid Ist 
file is found, check .cab file and Ford Root CA. Also useful 
for determining who interacted with the infotainment system 
based off name of USB device 

e ctx files store personal information — need to be located and 
content analysed 

e last know AM/FM frequencies and Sirius radio related 
information — useful for general localization information 


“mailbox” folder was discovered — no emails were found as of 
now, unsure if this feature was used. Pertinent to how long sent 
and received items are stored, or cached and for how long 
SYNC version and build number — if older version, helps 
determine if it can be exploited more easily and the hardware 
arrangement 

copyright information and involved partners — hints embedded 
technology 

profile Internet information — sub-folders include cookies, 
history and temporary Internet files but nothing was discovered 
inside these folders (possibility that the feature wasn’t recently 
used/or at all) 

graphical BMP files — geographical weather locations, perhaps 
relates to GPS data 

OpenSSL is used — potential “Heartbleed” vulnerability 
SQLite is being used for database formation and management 
many databases were found relating to fuel price listings, WiFi 
network listings, movie listings, etc. 

database entries and associated attribute values 

header files and related information 

“dummy” file used for creation of CAB file 

large amount of various log files — GPS.log, version.log, 
Database.log, etc. 

“www” folder found — Windows CE Web Server is enabled by 
default 

ECU response was located — interaction with other device apart 
from infotainment modules. Size of response displayed 
as well as hexadecimal values (address of other ECU device?) 
climate state/configuration — potentially helps determine if a 
vehicle was left inside/outside as well as general temperature 
of environment 

odometer readings are displayed in some files — useful for 
determining total distance travelled from last known point 
cryptographic seed found — potential use for authentication 
and/or breaking it for more access 

GPS related information — source/destination 

GPS favourite and “my home” information — longitude, latitude, 
altitude, city, state/province, etc.). “User data” folder found 
that holds this type of information. For e.g. movie listings and 
searches, fuel prices and gas stations nearby, etc. 

mobile carrier vehicle is connected to 

broadband information — username, password, phone number, 
carrier and country data set found. Fields were empty in this 
case so feature might not of been used 

configuration logs and device profiles — for e.g. NVRAM 
configuration, USB modem configurations, specific libraries to 
use with specific devices, etc. 

Bluetooth firmware version — potential vulnerabilities in older 
versions 

active audio sources, USB port and Bluetooth device statuses 
Windows CE version — potential vulnerabilities in older 
versions 

basic attributes of entire file system and associated content 
encoding used is ISO-8859-1 and Windows-1252 — will help 
determine and reveal more information 

private key file referenced — privkey.pm but location doesn’t 
exist therefore must be hidden with associated directories 
certificates in binary blobs — located in log files and 
“validcert.com” is referenced as a CA, needs to be confirmed 
if only CA or if there are others 
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e VIN number potentially located — 1FTFWIETXDFA48559 
(useful for booting infotainment and testing, will need to 
confirm) 

As shown above, a multitude of information can be found. Some 

of it can be less relevant to forensics and analysis but can be useful 

in terms of attempting to exploit the device for easier and quicker 
data access and extraction. The log files found show an interesting 
amount information. Two of them recorded events over a giving 
time frame. At this moment, we are unclear how long these log 
files store the information for and if it is a continuous log. We will 
be looking into if they record at certain specific events or randomly. 
It is important to note that latitude and longitude information can 
be found in these two specific logs when the system displays the 
amount of available memory. Based off Google map searches 
using the retrieved latitude and longitude coordinates, they are not 
random and correspond to the vehicle’s actual location at the time 
of display. An interesting amount of configuration logs have also 
been retrieved which let us know more about the exact 
configurations used by the system. It’s unclear why they would be 
accessible this way as they shouldn’t be attained by a regular user 
regardless. Other relevant information we found shows when the 
vehicle doors open, when it’s put in reverse (camera activates so 
potentially parking-aid engages), when an external device plugs in, 
etc. Some of the recorded events make references to other events, 
functions and DLLs being called in so we will need to look into 
these bits further to determine if more information can be acquired. 

We also need to determine the exact time frame as timestamps are 

not regularly used for logging, as far as we have observed. 


Overall, based off this preliminary analysis, it is safe to say that the 
Ford SYNC infotainment system, in the very least, holds a 
considerable amount of data that is worth looking into. What 
would be more interesting and needs to be looked into is the 
Bluetooth component of infotainment systems since more personal 
data is held onto modern phones. It would be important to have 
such a device connected to the SYNC module for further analysis. 
This would help determine to which extent data is being 
migrated/copied to the infotainment platforms. It is important to 
note that privacy is not our main concern in this work. We are 
focusing on identifying what can be stored in memory of 
infotainment systems. 


5.3 Ford SYNC physical dumps 

The logical dump shown above truly displays the forensic potential 
that can be found using infotainment system found inside vehicles. 
Two extra Ford SYNC systems were acquired and successfully 
powered on for data extraction. One was of the first generation and 
the other of the second generation. With the use of the specialized 
tool iVE, developed by Berla, JTAG acquisition was used to extract 
the data. The following lists the current data analysed and found 
within these modules. 


SYNC GEN I: 
e Device list with name of owner, serial number and entire 
musical playlists with visited radio channels 
Contact names found in arbitrary files 
Music information found in arbitrary files 
Unformatted/unallocated text message data related files 
System and user HV files found (registry data for 
Windows Mobile operating systems) 
e Database files with partial information relating to what 
appears to be user activity on infotainment system 
e Windows crash dump file found 
e System events log files 


e Entire phonebook stored 
e Index.dat files stored (unused due to lack of features of 
infotainment system) 


SYNC GEN II: 
e Large amount of log files relating to interactions with 
vehicle 


e Bunch of arbitrary information relating to system 
configuration (potential security keys, certificates, CA 
location, DNS information, etc.) stored in VOL and HV 
files 

e OpenSSL configuration file (shows 
certificates, private key, etc.) 

e Found devices that have been connected, including 
phonebook contacts and media playlists 

e Found arbitrary configuration data and some log 
information (odometer reading and timestamp read off 
vehicle at that moment... ECU response also found) 
Detailed information about media (mainly music related) 

e HV and VOL files containing user related data (phone 
numbers, emails, contact names, etc.) 

e Mailbox folder with inbox and outbox (nothing found, 
feature could have been not utilized) 

As predicted, the physical dumps of the infotainment systems 
contain a lot of information relating to personal data (especially 
data relayed from Bluetooth/externally connected devices). Some 
of the information found relates to system data but, just as in the F- 
150 case, this can also be used to further push research efforts and 
prove certain aspects when it comes to how data is handled, stored 
and processed for forensic use and analysis (for e.g. system time 
stamps could put suspect at an exact location at an exact time). It 
is important to note that some analysis is still left to be done on 
these systems but these early results show promise in the forensic 
use of vehicles and respective infotainments systems. 


location of 


5.4 Current progress — aftermarket system 

At this stage in our research, we are currently testing two Android 
based infotainment system as well as another Windows CE based 
system (non-SYNC related). Extracting the data off these systems 
was much more straightforward as Android is not proprietary in 
nature and Windows CE as its base form is easy to exploit. The 
operating system on these modules are as followed: Kit-Kat 4.4.4, 
Android 4 variant (Apple CarPlay and Android Auto ready with 
modified operating system) and Windows CE 6. The following 
methodologies have been employed to extract the data off these 
devices. 


Android Kitkat 4.4.4: 


e Root device through factory settings with following code: 


*#hct#root# 

e Download and install terminal emulator 

e Enable Android Debugging through terminal with ADB- 
over-WiFi 

e Terminal into system through PC with ADB utility 
through Android SDK tools 

e Gain root access and use “dd” for extraction 


Apple CarPlay/Android Auto Android system: 
e Format USB to FAT32 and insert special key file to 
enable testmode on device once connected to it 
e Write “dd” scripts to USB 
e Run scripts from USB device to extract data 
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Windows CE 6: 
e GPS SD card with executable found on device 
e GPS button on system maps to a specific path on file 
system 
e Move arbitrary software to SD card and remove GPS .exe 
to enable us to access Windows’ explorer.exe so we get 
full access to file system from within infotainment 
system 
e Run forensic tools to extract data to SD card 
These methodologies have proven to be (somewhat_ successful in 
acquiring data and having it analysed. It is important to note that 
these acquisition are not entirely complete as some files / portions 
of the file systems might be missing and other means of obfuscation 
such as encryption or compression have been employed. The 
following will list all pertinent information found so far as we are 
currently still testing and experimenting with these modules to 
verify if other means of extraction are possible and more effective 
in acquiring full physical dumps. 


Android Kit-Kat 4.4.4: 

e Google system user account found in clear text 

e Most of the file system’s extracted data is compressed or 
encrypted (further analysis is required) 

e Some blocks are not being parsed by Autopsy forensic 
toolkit (further research needed for alternate extraction 
method) 

Apple CarPlay/Android Auto Android system: 

e Deleted images can be recovered (in this case, wallpapers) 

e Most of the file system’s extracted data is compressed or 
encrypted (further analysis is required) 

e Some blocks are not being parsed by Autopsy forensic 
toolkit (further research needed for alternate extraction 
method) 

Windows CE 6: 

Incoming phone calls 

Missed calls 

Outgoing calls 

Full phone book 

Potential SMS information (SMS related files found but 
couldn’t be extracted due to system running... needs to 
be further looked into) 

Although the information found is limited, it still shows that 
forensic methodologies can be done to extract potential information. 
As mentioned above, more research will be done to determine 
better ways of extracting data so it can be analysed to its full extent 
for reporting. 


6. CONCLUSION AND FUTURE WORK 


As technology progresses, we are given more opportunities to stay 
connected in our daily tasks. With the near-future full 
implementation of VANETs, a high probability of vehicle drivers 
and passengers will have a safer, more efficient and user-friendly 
transportation system. The vehicle’s internal components are being 
redesigned for these purposes and interconnected for efficiency. 
Infotainment system will play a huge part for application use, 
localization and tracking. Digital forensics in vehicles must be 
further investigated in hopes of determining if these infotainment 
systems collect specific types of data. It is important to check if 
this data can determine anything about the users. Any type of data 
stored on infotainment systems has the potential to help forensic 
analysis when attempting to determine past events. Work in this 
area will be relevant as a limit can be identified on how much data 
is needed to be stored in these systems to ensure full usability and 


forensic use. All in all, infotainment system must be considered as 
an important source for forensics due to its practical operations. A 
lot of potential resides in these systems so research in its field is 
important and further work must be done to ensure a proper 
framework and methodologies are developed with appropriate 
forensic tools to enable forensic use for them. 


As shown above, not much research has been published on the topic 
of vehicular forensics. It is important that such work is not 
disregard as forensics is important for many instances, especially 
for law enforcement and evidence acquisition. Work in the popular 
infotainment brands is a good start as most modern vehicles will 
employ them. In the case of Ford’s SYNC modules, this would be 
a good starting point since these systems employ Windows CE as 
the base operating system, and forensic work on Windows based 
mobile platforms has already been done. It is important to note that 
Ford will be switching to a Blackberry-powered platform for future 
SYNC modules, but work on the Windows-based platform is still 
relevant since most vehicles on the road today use these current 
Windows-powered systems. Android platforms must also be kept 
in consideration considering their widespread use and open source 
elements. The latter could lead to a standardized methodology of 
extracting information off infotainment systems and this could be 
great for the open source community as more fixes could be applied 
in infotainment systems. Law enforcement could potentially 
benefit from such a framework as they could help identify and 
locate suspects in criminal investigations. 
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